Subject: Duplicate objects in appnGeneral and appnLocalGeneral

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Fri, 19 Jan 96 07:39:17 EST

Ref:  Bob Clouston's note (16 Jan 96)

I had taken a pass through these objects before I saw Bob's note, and
we reached many of the same conclusions.  Here's my pass:

First, I want to distinguish two types of redundancy for information
about the local node:

   - redundancy with other simple objects
   - redundancy with topology table entries for this node.

I agree that there's no justification for the first type of redundancy:
whenever we find two simple objects reporting the same information, we
should remove one of them.  In the second case, however, we can (and
have) argued that having simple objects, as opposed to table entries,
reporting on the node containing the MIB / subagent is useful enough to a
Management Station to justify a little redundancy.  We still believe
this.

Let's assume we have agreement on having simple objects to report
information about this node.  We still have these objects in two very
different places:  way up front on pages 10 and following, and further
back starting on page 61.  Our proposal is to group all of the simple
objects reporting on the local node near the front of the MIB, and remove
them entirely from appnLocalTopology.  That way a Management Station can
go one place to find out everything about the node it's talking to.

Let's go through the objects one by one; for ease of typing, I'll refer
to them with their OID labels.  "move to front" means to add the object
to the appnNnUniqueInfoAndCaps group that starts on page 15.

{ appnLocalGeneral 1 }     redundant with simple object:  remove it
{ appnLocalGeneral 2 }     redundant with simple object:  remove it
{ appnLocalNnSpecific 1 }  redundant with nnTopo table :  move to front
{ appnLocalNnSpecific 2 }  redundant with simple object:  remove it
{ appnLocalNnSpecific 3 }  redundant with nnTopo table :  move to front
{ appnLocalNnSpecific 4 }  redundant with nnTopo table :  move to front
{ appnLocalNnSpecific 5 }  retired from architecture:  remove it
{ appnLocalNnSpecific 6 }  redundant with nnTopo table :  move to front
{ appnLocalNnSpecific 7 }  redundant with nnTopo table :  move to front
{ appnLocalNnSpecific 8 }  redundant with simple object:  remove it
{ appnLocalNnSpecific 9 }  redundant with simple object:  remove it
{ appnLocalNnSpecific 10 } removed from architecture:  remove it
{ appnLocalNnSpecific 11 } redundant with simple object:  remove it
{ appnLocalNnSpecific 12 } redundant with simple object:  remove it
{ appnLocalNnSpecific 13 } redundant with simple object:  remove it
{ appnLocalNnSpecific 14 } redundant with simple object:  remove it
{ appnLocalNnSpecific 15 } redundant with simple object:  remove it

If we do all of this, we can also simplify the structure of
appnLocalTopology:

appnLocalTopology   OBJECT IDENTIFIER ::= { appnObjects 3 }
appnLocalTgTable       OBJECT IDENTIFIER ::= { appnLocalTopology 1 }
appnLocalEnTgTable     OBJECT IDENTIFIER ::= { appnLocalTopology 2 }

Note that this now makes a lot of sense:  local topology consists of a
table reporting on local TGs, and a table reporting on ENs' local TGs.

We're also a little confused about what's happened with the *Rsn
objects.  I can't find anything in the mail log to support this, but
Mark Zelek and I both recall that appnLocalTgRsn was removed back in
the summer because BobC argued that it made no sense.  Maybe we can
straighten out all of the *Rsn objects Monday.

Bob Moore